模組一｜為什麼把小說當專案管（Day 1–4）

先給你看一組數字，然後我們來討論它是什麼。

commits                197
時間跨度               2026-07-21 → 2026-08-05（16 天）

一天平均 12.3 個 commit。這個節奏你在任何一個趕上線的專案裡都看得到。

再看一眼內容：

novel/短篇/*.md                200 檔    61,405 字元
novel/*.md                      20 檔    （篇章封面）
docs/character-prompts/*.md     20 檔    （不含 index）
assets/turnarounds/*.png        20 張

看起來像個內容專案。但最後一項才是重點：

assets/    682M
.git/      849M

版本歷史比工作素材本身還大。

這不是一個小說專案的樣子。這是一個被當成軟體專案在跑、然後踩到軟體專案會踩的坑的東西。

這 30 天就是在講這些坑。

這個專案是什麼

《矽墟 · SILICA HOLLOW》是我的個人科幻創作專案。末日廢土設定，20 個篇章拆成 200 回短篇連載，13 個主要角色加 7 個 NPC，每個角色有立繪與三視圖，部分有章節封面與 3D 角色頁。

我先把話講在前面：這 30 天不講怎麼寫故事。

不講人物弧線、不講世界觀怎麼發想、不講靈感從哪來。你如果是為了看創作心得點進來的，這個系列會讓你失望。

因為做到一半我發現一件事——

真正吃掉時間的不是寫故事，是一致性管理。

四個讓我意識到「這是工程問題」的瞬間

一、角色的頭髮自己變了

我用 AI 生角色三視圖。同一個角色，前視圖是橘髮、側視圖偏紅、背視圖又變成棕的。

我以為是 prompt 寫得不夠細，於是把髮色寫得更精確。結果換成瞳色開始飄。

寫得更細也沒用，因為問題不在描述精度——參考圖裡的角色資訊會蓋過你的文字描述。這件事我花了兩個版本才想通，解法在 Day 11。

二、世界規則被我自己推翻

我在設定裡寫了「矽魂不進食、不老死」。

然後在某一回，我讓一個角色吃了東西。不是刻意的，就是寫到那個場景很自然地寫下去了。

一個人寫 200 回，你不可能記得自己在第幾檔寫過什麼規則。這不是記性問題，是缺乏約束機制的問題——Day 3 講怎麼把設定變成硬約束。

三、一個腳本重跑會燒掉一輪 API 費

我的三視圖生成腳本有「已存在就跳過」的邏輯，看起來很安全。

但成品後來全部改成英文檔名，而腳本比對的是中文檔名。比對目標永遠找不到，所以永遠不跳過。

我今天為了寫這系列去實測了一次，結果是：

這個 bug 不會報錯、不會 crash，每個角色照樣印 gen ... / saved ...，輸出看起來完全正常。唯一的症狀是帳單。 Day 16 專門講它。

四、我生出一個 3D 模型，然後整顆丟掉

我用 Microsoft 的 image-to-3D 模型跑出了一個角色的 3D 模型，13MB，附完整 PBR 貼圖。

最後上線的角色頁裡，那顆模型一行都沒用到。改成手寫幾何體重建。

這是本系列最重的一篇，Day 20 到 Day 25 整整六天在講這條路。

這些全都是工程問題

回頭看，這四件事沒有一件是「創作問題」：

左邊是創作者會遇到的煩惱，右邊是工程師每天在處理的東西。同一件事，只是沒有人用工程的語言描述過它。

而這正是這個系列的立場：創作專案長大到一定規模之後，瓶頸會從創意變成維護。 到那個時候，你需要的不是更多靈感，是版控、規格、產線，和一份寫清楚的約束。

代價：這套做法不是免費的

我不想把這系列寫成「工程化萬歲」，所以第一天就先講代價。

代價一：規格會壓縮即興。

我後面會講到一條規則——每回 20 到 35 句，第 5、10、15、20 句附近必須有一次反轉。這條規則確實讓連載的節奏穩定了，但它同時也意味著：我不能在某一回突然想寫一段三千字的抒情。

寫作的爽感是有被犧牲掉的。這點我不打算粉飾。

代價二：前期投入看起來像在浪費時間。

寫世界觀聖經、寫角色 prompt 檔、寫章節狀態表——這些東西一個字都不會出現在讀者眼前。在還只有 10 回的時候做這些，看起來就是不務正業。

它的回報要到規模上來才出現。如果你的專案不會長到那個規模，這整套是純虧的。

代價三：.git 849M。

這就是把二進位素材丟進版控的下場。686M 的圖片反覆修改、反覆 commit，歷史就這樣長起來了。

這個代價我到現在還沒付清——它已經在那裡了，clone 一次就知道。

帶走什麼：什麼時候該把創作專案「當專案管」

如果你手上也有一個持續長大的個人專案（不限小說——可以是素材庫、教材、文件站、影音企劃），下面三個訊號出現任一個，就該開始了：

訊號一：你開始需要回頭查自己寫過什麼。

不是「想不起某個細節」，是你必須真的去翻檔案才能確認。這代表專案的規模已經超過你的工作記憶，而人腦不會因為你更努力就擴容。

訊號二：同一件事你做第三次了。

第一次是嘗試，第二次是巧合，第三次就是產線。第三次還在手工做，之後每一次都會是手工做。

訊號三：你做了一件事，但無法說明它為什麼是對的。

「這張圖看起來對」和「這張圖符合 mustMatch 清單的第 3、5、7 項」是兩種不同的狀態。前者只有你能判斷，而且明天的你可能會有不同答案；後者可以被檢查、被交接、被自動化。

三個訊號都是同一件事的不同面向：你的判斷力開始不夠用了，需要把它外部化成規格。

這 30 天怎麼走

三個承諾：

1. 數字都是實測的。 檔案大小、字元數、commit 數、失敗次數——全部來自實際跑過的命令，不估算。上面那些數字你都可以在文章裡看到我怎麼量的。
2. 失敗優先。 NSFW 誤判、風格漂移、冪等性壞掉、13MB 模型丟掉不用——這些是主幹，不是花絮。
3. 每篇都有可以帶走的東西。 腳本、prompt 結構、成本數字、判斷準則。寫不出來的那天，題目就不成立，我會砍掉重排。

明天 Day 2，講第一個具體做法：世界觀文件怎麼當 single source of truth，以及一個我覺得比「集中管理」更關鍵的分工——知識文件和執行表為什麼必須是兩個檔案。